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ABSTRACT 



A properly designed user interface has the potential to greatly 
enhance an application by reducing user effort and enhancing 
interaction. This thesis designs and develops a prototype 
Graphical User Interface (GUI) for Co-oP, a Group Decision Support 
System (GDSS) for Cooperative Multiple Criteria Group Decision 
Making. The GUI has been created in a Windows operating 
environment and intended to be used on an IBM compatible micro- 
computer. Design methodology builds upon general interface design 
principles of User Control, Screen Design, and Screen Layout 
utilizing standard GUI control mechanisms. 
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I. 



INTRODUCTION 



A. PURPOSE OF THESIS 

The purpose of this research is to design a prototype 
Graphical User Interface (GUI) for Co-oP, a Group Decision 
Support System (GDSS) for Cooperative Multiple Criteria Group 
Decision Making. This user interface will substantially 
increase the value of the Co-oP model, "...as an experimental 
tool to evaluate the effectiveness of group Decision Support 
Systems in supporting group decision-making." [Ref. l:p. 3], 
by developing an effective user-friendly interface that 
encourages broadened user participation. 

B . BACKGROUND 

Co-oP was designed to study the possibility of creating a 
GDSS that supports both content -oriented and process -oriented 
decision techniques [Ref. l:p. 117]. Furthermore it was to 
provide users with a communications network in order to 
support a distributed GDSS by setting up communications 
parameters and group norm definitions prior to initiating the 
group decision process. 

1. System Overview 

Co-oP is intended to be a microcomputer-based process - 
driven DSS in which each participant of the group has his own 
DSS whose model base is based on multiple criteria decision 
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methods (MCDM) along with additional personal DSS tools [Ref. 
l:p. 118] . The GDSS contains sets of aggregation preferences 
techniques and consensus seeking algorithms that can be used 
with individual MCDMs. The microcomputer network system is to 
be linked together using Local area network [Ref. l:p. 118] . 
Originally written in Turbo Pascal, a nvimber of the Co-oP 
routines have been updated to C in 1987. In order to follow 
an unambiguous and uniform flow of information, Co-oP follows 
the basic steps of a multiple criteria problem solving process 
(see Chapter II, section C.l). First, the group must select 
and identify a decision problem. This includes determining 
the set of alternatives along with evaluation criteria. 
Secondly the group must identify members and set communication 
parameters. These parameters include data transfers, 
interactive conversation, utilization of electronic mail, and 
types of decision techniques [Ref. l:pp. 121-124]. The third 
step involves individual evaluation prioritization. This 
includes methods of assigning weights to criteria directly, 
for example ELECTRE, or using a hierarchical prioritization 
scheme (e.g.. Analytical Hierarchy Process). These methods 
can be utilized in a pooled mode in which all group members 
collectively enter a priority vector, or as single user DSS 
with communication support. The fourth process allows users 
to individually evaluate alternative using his preferred or 
familiar MCDM. In the current version, these methods include 
ELECTRE, the Analytical Hierarchy Process, or direct 
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individual ranking. The next step of the process is the 
computation of group results using four techniques of 
aggregation of preferences. If unanimity is not obtained, a 
consensus seeking algorithm can be evoked or the decision 
makers can revise their individual evaluations. 

2 . Model Components 

The main purpose of the MCDM model bank is to provide the 
decision makers a set of models that can solve the most common 
types of decision problems [Ref. l:p. 126]. Co-oP contains 
three models that cover selection, ranking, and sorting. 
These methods are not difficult and interact with techniques 
of aggregation. 

The ELECTRE method is characterized by circumventing the 
problem of incomplete comparability of alternatives through 
the concept of outranking relations [Ref. l:p. 127]. Two 
reasons a decision maker finds it difficult to compare 
alternatives are the to uncertainty associated with 
measurements and evaluation, and incomparable alternatives. 

The Analytic Hierarch Process (AHP) method supports 
complex decision problems by successively decomposing and 
synthesizing various elements of a decision situation [Ref. 
l:p. 131] . AHP permits subjective and qualitative comparisons 
by measuring levels of priority in a pairwise relation, 
creating a reciprocal matrix of pairwise comparisons. 
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3 . Communications Module 



Co-oP provides for the following functions: coordinate 
information exchange, enforce communication protocols, search 
for data compatibility for group algorithms, and sort data for 
diffusion [Ref. l:p. 136] . A group norm constructor in Co-oP 
allows users to define a framework for communications exchange 
in support of the decision making process. The group users 
through the group norm agrees upon decision techniques, 
techniques of aggregation and which weighted majority rule to 
be complied with. Information exchange parameters such as 
broadcasting of outputs to selected users are supported. The 
group norm allows users to modify individual inputs and also 
sets a time limitation in which to submit inputs. In 
addition, a bulletin board or electronic notepad can be used 
as a format -free mechanism for group members to exchange 
ideas. To protect information, password identification is 
required by members of the group norm. 

4 . Interface Component 

The Co-oP interface was designed to provide a simple 
unambiguous and standard man-machine interface allowing users 
to concentrate on the core of the problem [Ref. l:p. 140]. 
During the problem and group norm definition phases, a outline 
form data entry format is used. In the Pascal version of Co- 
oP, a typical screen format displays four different windows 
simultaneously. The Step window identifies current process 
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and displays any required diagnostic messages or prompts. The 
Dialogue window provides a conversational medium utilizing a 
Question/Answer mode of interaction. The Working window 
displays vital information from dialogue or inputs and 
displays other group members results. The Solution window 
displays immediate and final results in the format of tabular 
outputs, graphs, and statistical indexes. Co-oP also utilizes 
different colored screens and text to allow easy recognition 
of various displays. In order to provide the users with a 
structured, simple and controlled framework for the model, Co- 
oP combines menus and questions for communication with users. 

C. SCOPE OF RESEARCH 

The scope of this research includes the prototype design 
of a user interface for the Co-oP Group Decision Support 
System model utilizing a programming system for Windows 
environments. Interface design is patterned on current GUI 
standards. Individual screen designs will be discussed in 
depth as to their design methodology in relation to the Co-oP 
model . 

D. THESIS ORGANIZATION 

Chapter II reviews general design principles and specific 
design considerations for Co-oP. Chapter III presents 
individual screen designs and provides an in depth analysis of 
screen architecture, including limitations and benefits of GUI 
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guidelines in conveying current Co-oP model requirements. 
Chapter IV provides a summary of findings and guidance for 
future considerations. 
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II. INTERFACE DESIGN PRINCIPLES 



A. GRAPHICAL USER INTERFACES 

Current trends in software applications are increasingly- 

taking into account how the user will interact with the 

computer. According to Hooper [Ref. 2:p.9], 

"In research on interface design we frequently allude 
to the creation of environments for enhanced 
interaction and problem solving." 

Designers are now recognizing that along with new advances in 

hardware technology and expanded computing capabilities, that 

ultimately end user use determines how successful an 

application actually is. Hooper adds [Ref. 2:p.9], 

"Similarly we often distinguish the aesthetics of an 
interface from its functionality, and we emphasize the 
importance of the satisfaction of a human user as a 
criterion for evaluation rather than the objective 
analysis of the technological power of a particular 
system. " 

In responding to human user satisfaction as a criterion for 
evaluation, and thus considered as part of design 

considerations, graphical interfaces are becoming the 
designers interface of choice. Popularized in 1984 by the 
Apple Macintosh, this type of interface has come to be known 
as Graphical User Interface (GUI) [Ref. 3:p.250]. 
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1. Design Principles of Graphical User Interfaces 

Conveying information about data and functions visually 

allows designers the ability to accurately model applications. 

According to Gaines and Shaw [Ref. 4:p.80], 

"Users will model the computer system and form new 
expectations based on their interaction with it. The 
system should be designed to induce accurate models and 
correct expectations." 

In order for a user to fully benefit from an application, he 
must first be able to interact with it. This interaction 
begins at the interface both in its controls and the way 
information is displayed. In modeling the application, the 
interface must be easy to understand. If the user has 
difficulties with understanding the application as a result of 
a complicated or incomplete computer interface, his attention 
is diverted from the application and his understanding of the 
problem or overall work effectiveness suffers. A properly 
designed graphical user interface parallels the application 
model both through control and data exchange. This alleviates 
user communication anxiety and allows him to concentrate on 
the task at hand. 

2 . GUI Components 

There are currently several organizations marketing 
graphical interfaces that share some but not all common 
features. Table 1 lists some of the larger GUI products along 
with their associated organizations. The following is a list 
of parts typically associated with a GUI [Ref. 3:p. 250]; 
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• a pointing device, typically a mouse 

• on-screen menus that can appear or disappear under 
pointing-device control 

• windows that graphically display what the computer is 
doing 

• icons that represent files, directories, and so on 

• dialogue boxes, buttons, sliders, check boxes, and a 
plethora of other graphical widgets that let you tell the 
computer what to do and how to do it 



Table 1. CURRENT GRAPHICAL USER INTERFACES 



Organizations 


Product 


Aoole 


Macintosh 


Microsoft 


Windows 


IBM with Microsoft 


OS/2 Presentation 


Digital Eauinment Coro. 


DECwindows 


Ooen Software Foundation 


Motif 


Santa Cruz Operation (SCO) 


Open Desktop 


Commodore Amiga 


Intuition 


NeXT Computer 


NeXTStep 


Digital Research 


GEM 


Sun Microsystems 


Open Look 


Hewlett-Packard with Microsoft 


Common X Interface 


Hewlett - Packard 


NewWave 



Source: [Ref. 3] 



Additionally the following is a list of some common GUI 
controls : 

• Command button: Performs a task when chosen by the user. 

Some examples are the "OK" button, the "Cancel" button, 
and the "Enter" button. 
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• Check, box: Displays an option that can be turned on or 

off. Check boxes may be used in groups to display 

multiple options, 

• Option button: Sometimes referred to as the "radio 

button" displays an option that can be turned on or off. 

• Combo box: This control allows the user to make a 

selection by typing text or selecting an item from the 
list below it. 

• List box: Displays a list from which the user can choose 

one. 

• Text box: Can either display information that is 

specified or that the user enters. 

• Action bar: Also known as the Action Menu provides a 

means of displaying selectable drop down menu boxes. 



Not all GUIs have all these features. Some may not 

accommodate a pointing device or lack visual features such as 

icons or other specific graphical devices. Hayes and Baran 

have identified three similarities [Ref. 3:p. 250], 

"...most GUIs consist of three major components: a 

windowing system, an imaging model, and a application 
program interface (API)." 

The windowing system is described as a set of programming 
tools and commands that are used to build interface windows 
and include the menus, controls, dialogue boxes, and commands 
that make up the interface. The imaging model defines the 
creation of fonts and graphics. Two examples are Macintosh's 
Quickdraw and Microsoft's Graphic Programming Interface for 
OS/2. The API is a set of programming function calls and is 
how the programmer specifies what graphics will appear on the 
screen. 
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While Hayes and Baran have defined a GUI in terms of three 
components, Myers identifies the user interface as a logical 
part of the window manager [Ref. 5:p. 67] . He identifies a 
base layer that implements the functionality of the windows 
manager. It consists of two parts, one to handle the display 
of graphics and a second part to access input devices. Termed 
the program interface or application, it has a primary purpose 
of interfacing with other programs . The second layer is the 
user interface. This is the visible layer and is further 
broken down into two parts . The layer associated with 
pictures or displays is termed presentation, and the layer 
which allows the user commands to manipulate controls is 
termed operations. 

In the development of Co-oP's prototype GUI, the 
representation of the underlying application is emphasized. 
According to IBM's Advanced Interface Design Guide, the 
designer of an interface provides the screen components which 
best support that application [Ref. 6:p.3] . In following 
current trends in emphasizing the visual interface as a means 
of encouraging user understanding and participation, this 
prototype GUI, being developed in Visual Basic, emphasizes the 
user's perspective in presenting an application. 

B. GENERAL DESIGN PRINCIPLES 

Design guidelines for GUIs are not revolutionary but 
continuations of established principles. An interface should 
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present a clear, organized representation of the application 
it is conveying. Shneiderman identifies 8 underlying 
principles of design [Ref. 7:pp. 60-62]; 

• Strive for consistency 

• Enable frequent users to use shortcuts 

• Offer informative feedback 

• Design dialogues to yield closure 

• Offer simple error handling 

• Permit easy reversal of actions 

• Support internal locus of control 

• Reduce short-term memory load 

Consistency in an application includes controls, commands, 
actions, terminology, menus, and screen layout. By enforcing 
consistency, the designer is able to reinforce an application, 
allowing the user to concentrate on the problem as his 
interaction through the interface become secondary. The use 
of special keys and commands allow the knowledgeable users to 
reduce the number of interactions through shortcuts. 
Windowing interfaces can be easily manipulated by the 
experienced user to quickly navigate through an application. 
Visual feedback allows users to see consequence of actions, 
whether it be an error message or subtle change of color. 
Providing a sense of closure allow the user a feeling of 
accomplishment and termination to the current action and 
enables him to move on to the next action. Error handling 
should be simple. Provide detection mechanisms and easy 
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correction capability. The user should not worry that 
improper commands or input would adversely effect data. Easy 
reversal of actions allow the user to explore the system free 
from the anxiety of making mistakes that cannot be easily 
corrected or have adverse effect on the application. Allow 
the user to be in control. His actions should be by choice 
rather than responding to rigid sequential input. Reduce 
memory effort of the user by simplifying screens and sequence 
of actions. User actions should be obvious with appropriate 
help mechanisms to alleviate the amount of information the 
user must work with. These principles of dialogue design 
readily equate to the design of visual interfaces. The 
designer strives for an interface that is easy to control, 
simple to understand and will reinforce the users expectations 
of the application. 

The enhancement of the user interface must convey an image 

of the application. Merely making an interface graphically 

appealing is not a means to making it more effective. 

Regarding the design of GUIs, Marcus notes [Ref. 8:p. 107]; 

"Graphic design can help GUIs achieve their potential to 
communicate. Information- oriented, systematic graphic 
design is the use of typography, symbols, color, and other 
static and dynamic graphics to convey facts, concepts, and 
emotions . " 

He further identifies three principles as a useful guide to 

research and development [Ref. 8] ; 

• Organize: Provide the user with a clear consistent 

conceptual structure. This includes concepts of 
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consistency both in screen design and controls, and 
navigability through the application. 

• Economize: Maximize the effectiveness of a minimal set of 

cues. Limit the number of controls to what is absolutely 
required and avoid unnecessary items. 

• Communicate: Match the presentation to the capabilities 

of the user. Communicate through visualization by 
balancing aspects of color, text, and symbols in 
representing the application. 



1. User Control 

In designing the visual interface, mechanisms of control 

should be balanced to accommodate both the experienced user 

and novice. Shneiderman writes [Ref. 9:p. 226]; 

"A driving force in hiiman behavior is the desire to 
control . Some individuals have powerful needs to attain 
and maintain control of their total environment; others 
are less strongly motivated in this direction and are more 
accepting of their fate." 

In accommodating the users perspective, three issues should be 
addressed. They include the number of controls, escape, and 
navigation. In addition, and of major concern from most 
authors is the concept of consistency, Marcus relates it to 
both consistency in conventions and rules [Ref. 8] . In terms 
of control, make commands familiar with similar consequence of 
action and reinforce consistency across the entire 
application. 

a. Number of commands 

Two factors are reinforced in terms of commands. Marcus 
writes, "Simplicity suggests that we include only those 
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elements that are essential for communication." [Ref. 10:p. 
121] . Myers notes that a large number of commands allow users 
to perform functions many ways but it may add difficulty in 
knowing which command to use [Ref. 5:p.78]. Simply put, 
minimize the number of commands and make them clear as to 
function. 

b . Escape 

Another control aspect is the users ability to escape a 
command or action. Shneiderman discusses user anxiety in 
terms of user ability in using computer systems and their fear 
of altering data [Ref. 9:p. 225-226]. When interacting with 
an application a user, in order to be in control, should be 
able to exit or escape a function without fear of altering 
data. This capability allows him to explore system actions 
and capabilities without fear of data corruption. As stated 
by Gaines and Shaw, "There should be a facility to enable the 
user to escape at will leaving the state of the system well 
defined." [Ref. 4:p. 81]. 

c. Navigation 

The user must be able to develop a sense of control over 
his actions, which includes both the concept of escape as 
previously described but also a sense of controlling 
subsequent actions. If the user for any reason needs to 
terminate an action or return to a previous application 
module, he should be provided that mechanism. Being caught in 
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a loop requiring user input before termination removes that 
sense of control . The application should avoid traditional 
modes of sequential input that restrict user interaction to a 
rigidly prescribed routing and allow the user to control or 
navigate through the application as it best meets his needs. 

2 . Screen Design 

The importance of the user interface relates directly to 
what the user sees. A effective screen design assists rather 
than hinders the users understanding of the application. The 
use of graphical displays enhance user visualization. The 
designer must also curtail graphics as if they are overdone, 
they can overpower the user and complicate his problem 
understanding. According to Marcus, "You must select 
visualization techniques that are appropriate to the output 
display technology." [Ref. 10:p. 122]. He further identifies 
aspects of legibility, readability, typography, symbolism, 
view, and color. Three areas pertaining to a graphical 
interface need attention, color, screen layout, and 
typography. As in user controls, consistency is required 
across screen design. IBMs Advanced Interface Design Guide 
notes that users become familiar with interface components 
when the visual appearance of these components are consistent 
across applications [Ref. 6:p. 11]. 
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a. Color 



Marcus notes the use of color in graphical interfaces 
greatly enhances problem presentation if used correctly [Ref. 
ll:p. 135]. He adds, "Conversely, the inappropriate use of 
color can seriously reduce the functionality of a display 
system.". Marcus identifies three principles of color design; 
color organization, color economy, and color communication. 
Consistency, as inmost designs, guides organization. The use 
of similar colored backgrounds, controls, and cues allow the 
user to associate common displays. In presenting screens to 
users, avoid overly dazzling, multicolored displays. Restrict 
the number of colors to 5±2 for simplicity [Ref. 11 :p. 137] . 
Allow colors to communicate. Subtle color change add accents 
and separate areas of display. Contrasting colors are 
attention getters and could be used to draw focus for emphasis 
or warning. Shneiderman points out several guidelines for 
designers in relation to color use [Ref. 7:pp. 337-342]: 

• Use color conservatively 

• Limit the number of colors 

• Recognize the power of color as a coding technique 

• Color coding should support the task 

• Color coding should appear with minimal user effort 

• Color coding is under user control 

• Design for monochrome first 

• Color can help in formatting 

• Be consistent in color coding 
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• Be alert to common expectations about color codes 

• Use color changes to indicate status changes 

• Use color in graphic display for greater information 
density 

• Beware of the loss of resolution with color displays 
The bottom line in adding color to screen design is to use it 
to augment or highlight information, not over power the user 
with excess. 

Jb. Screen Layout 

Design considerations relating to screen layout include 
consistency, format, and user memory. As previously noted, 
consistency across screen designs needs to include layout. 
Common positioning of controls, text, menus, and forms all 
lead to ease of comprehension for the user. By enforcing 
consistency, the user, in becoming familiar with format, 
spends less time with the physical display and more time 
concentrating on the actual application. Designing format 
that is natural to what the user expects contributes to his 
ease of interaction. Neat forms, proper alignment, and simple 
labeling that reflect the problem all lead to ease of use. 
Avoid over powering the user with excessive clutter. 
Regarding screen layouts, Marcus advises the use of a grid 
structure, standard screen layouts, a group- related elements 
[Ref. 8]. Provide only the controls and displays that are 
needed by the applications current data exchange requirements. 
The way the screen is spatially organized as in color, can 
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help or hinder the user interaction. The use of menus, 
controls, and dialogue should be limited to current 
application requirements, 
c . Typography 

Typography consists of the typefaces and groupings of text 
in screen design. Marcus notes that one of the key elements 
to legibility and readability is the use of typography in 
design of the user interface [Ref. 10 :p. 123] . He further 

suggests to limiting typefaces to a maximum of three. The 
typeface chosen should be legible and distinctive and not be 
hidden in background clutter. 

C. GUI DESIGN CONSIDERATIONS FOR COOP 

Interpretation of the Co-oP model is in large part based 
on the current version's interface. Utilizing traditional 
menu format combined with sequential queries, it is rigidly 
structured. The interface itself is divided into four 
windows, the Step window, the Dialogue window, the Working 
window, and the Solution window [Ref. l:pp. 141-143]. See 
Figure 1. 
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Figure 1. Original Four Window Design 



Source: [Ref. l:p. 143] 

A primary concern in re-designing this interface is the 
incorporation of mechanisms allowing user control and 
establishing visual feedback specific to inputs requested by 
the user. Also mechanisms designed to alert the user to 
errors, and provide adequate help dialogues to assist him in 
utilizing the model through the interface. 

1. Interpreting the Model 

In interpreting the model, preservation of the multiple 
criteria decision method and other decision tools was 
paramount. Following the original interface, an appropriate 
way to insure required information flow is to follow a 
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multiple criteria problem solving process [Ref. l:p. 120]. 
This process consists of: 

(i) Group Problem Definition 

(ii) Group Norm Definition 

(iii) Individual Prioritization of Evaluation Criteria 

(iv) Individual Evaluation and Selection of Alternatives 

(v) Direct Evaluation of Alternatives 

(vi) Group Selection of Alternatives using techniques of 
aggregation of preferences 

(vii) Consensus seeking and negotiation analysis 

Note that step (v) may be substituted for steps (iii) and 
(iv) . This general format remains unchanged. The first step 
is collectively identifying and defining the problem and 
secondly identifying the group members and determining 
communication restrictions. The third step allows two methods 
of prioritizing evaluation criteria. The user chooses either 
the AHP or direct method of ranking. Step (iv) , evaluation of 
alternatives offers the AHP method, ELECTEE, and direct 
ranking to rate alternatives. As pointed out, step (v) may be 
substituted for both previous steps. Using four aggregation 
preferences, step (vi) computes group results. Finally, step 
(vi) permits a consensus seeking algorithm if a unanimous 
decision is not obtained. 
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2. Channeling Input 

In determining Interface design, input choices require 
careful thought. With numerous input devices such as simple 
text boxes, drop-down list boxes, or scrolling methods, to 
mention just a few, the method chosen is needed to reflect as 
much as possible what the user's mental image of Co-oP model 
dictated. Persistent to allowing the user to be in control, 
input mechanisms need to be broken down into steps easily 
understood and concentrated on and allowing a means of escape 
when completed [Ref. 9:p. 225] . This allows the user to break 
down input mechanisms into smaller, easily managed portions. 

3 . Limiting Output 

In designing for output, a major consideration was 
limiting information presented to the user. The combination 
of tables, matrixes, and graphs, as presented in the original 
interface tend to overpower the interface display and present 
a cluttered appearance. Limiting output to user requests 
again allow him to control presentations, and allow him to 
determine output requirements that meet his needs. In 
striving to meet this criteria, multiple, overlapping windows 
that are easily selected by the user enable customization of 
output that best serve his requirements. 

4 . Networking Issues 

Design of a DSS to support multiple decision making should 
also consider the developing technologies of computer networks 
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and electronic communication [Ref. l:p. 35]. Characteristics 
of distributed systems allow individual users the ability to 
process applications of a group decision support system that 
is independent of network technology. Bui identifies six 
possible types of DSS user interactions [Ref. l:pp. 39-42] : 

• Type 1: The traditional DSS paradigm with the user 

interacting directly with an individual DSS with no 
communications support. 

• Type 2: A group of users interacting with a DSS, usually 

with an intermediary. 

• Type 3 : Essentially a combination of the previous two in 

which each user interacts directly with an individual DSS 
with the addition of some type of electronic aggregation 
of preferences. 

• Type 4 : This DSS framework addresses the sharing of a 

GDSS but is loosely coupled and individuals lack knowledge 
about other group members . 

• Type 5 : This GDSS supports both individual DSS and group 

DSS as it provides a multilateral network relationship of 
shared DSS. 

• Type 6: This GDSS, as in the previous type represent a 

distributed problem solving system with individual members 
interacting with the system. Additionally Type 6 provides 
for a mediator. 

A networked GDSS can provide four main functions [Ref. l:p. 
45] : 



(i) monitoring of data exchange 

(ii) automatic selection of appropriate group decision 
techniques 

(iii) computation and explanation of a group decision 

(iv) suggestion for a discussion of individual differences 
or for a redefinition of the problem if attempts to 
reach consensus fail 
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The provision of networking in a GDSS allows for 
geographical dispersion of individual members. Communication 
can be either on-line or sequential, thus removing 
requirements for set times of participation and allowing each 
member the ability to interact at his convenience. 
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III. INDIVIDUAL SCREEN DESIGNS 



A. MAIN CO-OP SCREEN 

This initial screen design titled, Cooperative Multiple 
Criteria Group Decision Maker, is the user interface to the 
Co-oP model (see Figure 2) . Each labeled Command Button 
identifies one of the models seven problem steps and when 
clicked, opens that particular sub-module. The design itself 
represents a flow chart of how the problem is to proceed. The 
first two steps of a problem are the definition of problem 
alternatives along with criteria for measurement, and defining 
the group norm which includes identifying members and 
communication parameters. These first two steps must be 
completed before continuing the problem. The model then 
allows two courses of action, the first is to utilize the 
various model components to prioritize criteria and evaluate 
alternatives. An alternate second method, if chosen, allows 
the user to rank alternatives directly without going through 
formal alternative evaluations. Both These two methods lead 
into the group decision button which opens that module and the 
identifying of negotiable alternatives. The final command 
button exits the program. Command Buttons were chosen as a 
graphical representation of the flow of the Co-oP model over 
traditional menu driven selections. By presenting an overall 
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Figure 2 . 



Co-oP Main Screen 
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visual display of the application model steps, the user should 
gain an immediate understanding of model requirements and a 
sense of control over his actions. Additionally, two menu 
items are available from the Action Bar. The File menu 
provides choices relating to document saving by access to a 
dialogue box and an additional exit selection. The Help menu 
provides choices of a general help screen and data about the 
interface . 

B. GROUP PROBLEM DEFINITION MODULE 

This module correlates to step (i) of the Co-oP 
application (see page 20) . The current prototype module 
contains five main screens. Three screens are dialogue boxes 
with minimal information requested from the user. The 
remaining two screens requiring the user to define both 
problem Alternatives and Evaluation Criteria, involve text 
input. In addition there are various additional Help, 
Password, and Dialogue boxes that will be covered in 
miscellaneous screen designs. 

1. Problem Identification Screen 

This simple dialogue box allows the user to select via 
radio buttons whether he desires to define a new Group Problem 
or open a previously defined Group Problem (see Figure 3) . 
The OK button accepts whatever choice he makes and the Cancel 
Button returns the user to the Main screen without accepting 
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any user input. The default selection is to define a new 
Group Problem. 

2. Problem Files Screen 

This interface allows the user to select a previously 
defined problem file for use in his current application 
session (see Figure 4) . It contains visual fields indicating 
current drive, directory, and associated problem files that 
are restricted to files with a .def extension. All data 
relating to the problem definition will be maintained in this 
file. In addition current path is displayed in a text box for 
the users reference. The user has a choice of three Command 
buttons. The OK command button selects user file selection. 
The Cancel button accepts no file and returns the user to the 
Problem Identification screen. And finally the Help button, 
which is intended to access an informative screen guidelines 
dialogue box. 

3. Problem Definition Screen 

This screen interface allows the user to select either 
Identification of Alternatives or the Evaluation Criteria 
Hierarchy selection via radio buttons (see Figure 5) . This 
dialogue box allows the user to enter the Problem Name if a 
new problem is to be defined or display the problem name if a 
previous problem was selected via a text box. The OK button 
accepts user choice with the Identification of Alternatives as 
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Figure 3 . 



Problem Identification Screen 




Figure 4. Problem Files Screen 
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the default value and the Cancel button returns the user to 
the Problem Identification screen. Additionally, this screen 
has File and Help menus accessed through an action bar. These 
additional dialogue box functions will be discussed in general 
in miscellaneous screen designs. 

4. Identification of Alternatives 

This screen allows the user to input up to 15 alternatives 
for the group to evaluate (see Figure 6) . In determining the 
number of alternatives, screen limitations in the design 
software aesthetically limited this prototype to 15 choices. 
Ideally the number of alternatives should allow up to 40 
choices. The Group Problem Name is automatically displayed 
for reference at the top of the display in a text box. The 
screen is formatted for up to 15 choices, of which only two 
are initially displayed, the rest being hidden until the user 
selects additional alternatives to enter via an Add 
Alternative Command button. Conversely, if the user wishes to 
eliminate alternatives he can use a Delete Alternative button 
to remove in reverse order, his number of choices. The Enter 
button accepts user input while the Cancel button returns the 
user to the Problem Definition screen display. This screen 
also introduces a Help button with the "?" caption. By 
utilizing a Command button for additional help screen access, 
it is graphically incorporated into the screen format vice 
having a single Help menu option on an action bar. 
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Figure €. Identification of Alternatives Screen 
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5. Hierarchy of Evaluation Criteria Screen 

This screen interface allows the user to input via text 
boxes a hierarchy of evaluation criteria (see Figure 7) . 
There are three levels of hierarchy with up to ten choices 
available at each level. The default display is the first 
level indicated by the three Radio buttons in the Select Level 
frame box. Additionally, if further levels of detail are 
required for criteria evaluation, the user can select a second 
or third level which is based on the previous levels selection 
number. An additional dialogue box corresponding to that 
level will overlay the current window and allow for similar 
format of data entry allowing further amplification of user 
input relating to current level selected. The default 
selection is to define a new Group Problem. The Group Problem 
Name is displayed for user reference in a text box near the 
top of the screen. The enter button accepts inputs and the 
Cancel button returns the user to the Problem Definition 
Screen. As in the previous screen design. Add Criteria and 
Delete Criteria allow the user to modify the number of 
criteria for input. 

C. GROUP NORM DEFINITION MODULE 

This module corresponds to step (ii) of the Co-oP 
application (see page 20) . This current prototype module 
contains ten primary screen interfaces. Four of the screen 
designs are dialogue boxes with minimal input required from 
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Figure 7. Hierarchy of Evaluation Criteria Screen 
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the user. Two screens require text input that use an updated 
f ill-in-the-blank format. The remaining four screens utilize 
either radio button or check box functions for user input. 
Screen formats were designed to focus the user on current data 
exchange requirements without excessive screen clutter. 

1. Group Norm Identification Screen 

This screen interface is similar in design to the Problem 
Identification screen on page 26, (see Figure 8) . The user is 
given a choice of defining a new group norm or selecting a 
previous definition via radio button selection. The OK button 
accepts user input and the Cancel button returns the user to 
the Main Co-oP screen. The definition of a new group is the 
default . 

2. Group Norm Files Screen 

The user is allowed to retrieve a previously defined group 
norm for the current session (see Figure 9) . Utilizing the 
same layout as the Problem Definition Screen (see page 27) , it 
has visual references to the drive, directory, and 
corresponding files with a .GN extension. All data pertaining 
to the Group Norm parameters will be maintained in this file. 
Additionally, the current path is displayed for user 
reference. The command button OK accepts the highlighted 
group norm file for manipulation. The Cancel button returns 
the user to the Group Norm Identification Screen without 
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Figure 9 . Group Norm Files Screen 
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accepting any input. The Help button "?" will provide access 
to help documentation. 

3. Group Norm Definition Screen 

This interface functions much the same way as the Problem 
Definition Screen (see page 2 7) . Through radio button 
selection, the user is able to select either Identification of 
Group Members, Group Decision Techniques, or Infoinnation 
Exchange (see Figure 10) . If not a previously defined group 
norm, the user enters a group norm name in the text box 
provided. The Enter button accepts the users radio button 
selection and displays that corresponding screen interface. 
The Cancel button returns without accepting any data to the 
Group Norm Identification Screen. When the user completes 
selection and data input of all three radio button options, a 
dialogue will promipt him to save that data. Two additional 
controls, a File menu selection and a Help menu selection are 
located on an action bar at the top of the screen. 

4. Identification of Group Members Screen 

This dialogue box is displayed when the user selects the 
first radio button on the Group Norm definition screen. It 
consists of three text boxes (see Figure 11) . The first text 
box allows the user to identify the Group Norm builder. The 
second input is a five character group password. The last 
input is the number of decision malcers in the group. The 
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Figure 10. Group Norm Definition Screen 




Figure 11. Identification of Group Members Screen 
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Enter button accepts data input and the Cancel button returns 
the user to the Group Norm Identification screen. 

5. Decision Makers Screen 

This screen interface consists of simple text input into 
appropriate text boxes (see Figure 12) . Up to 15 group 
members are allowed. Although 15 members are available, only 
the appropriate momber of text boxes required are visible as 
indicated by the third input on the previous screen, the 
remaining unused text boxes remain invisible. Selection of 
the Enter command button accepts the group list and the Cancel 
button returns the user to the Identification of Group Members 
screen. 

6. Group Decision Techniques Screen 

Through this screen interface, the user defines the 
framework for the group decision techniques (see Figure 13) . 
Specific areas covered include: 

• weighing members input 

• restricting the members input based on his area of 

expertise 

• members decision technique to be used in group decision 

• selection of techniques of aggregation of preference 

• computation of NAI 

The interface allows, via radio button selection, the members 
to set up decision techniques before continuing with an 
individual session. Radio button default values are displayed 
in individual frame boxes. If, as a result of button 
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Figure 12 . Decision Makers Screen 
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Figure 13 . Group Decision Techniques Screen 
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selection, further amplification is required, additional 
screens will overlay the current screen requesting additional 
input. The Enter button accepts the data input and the Cancel 
button returns the user to the Group Norm definition screen. 
Help mechanisms are not available as the text is self 
explanatory. 

7 . Individual Decision Weights Screen 

This screen is displayed when the "No" radio button is 
selected for weighted majority rule. By default, each group 
members inputs are weighted equally. This interface allows 
the group members (up to 15) to be assigned different decision 
input weight. The actual weights can be either input directly 
by the group or manipulated through sliding boxes that 
incrementaly increase or decrease a members decision weight 
factor (see Figure 14) . Selection of the Enter button accepts 
input and the Cancel button returns the user to the Group 
Decision Techniques screen. In addition a Help button would 
allow additional amplification of how to input and manipulate 
the sliding boxes. 

8. Individual Criteria Selection Screen 

This screen, as in the Individual Decision Weights screen, 
appears as result of not selecting the default choice in the 
collective evaluation modes frame box. The default value 
allows each member to evaluate alternatives based on all 
criteria. Although not available in the current version of 
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Co-oP, this capability, included as part of the prototype 
interface allows the group to selectively choose areas of 
expertise for individual members to evaluate alternatives. 
The screen is designed to allow the group to easily select 
criteria for evaluation for each individual member who is 
identified by number (see Figure 15) . Check boxes can either 
represent individual areas of criteria to be included or as 
areas to be suspended for that particular member. Only the 
first criterion layer is to be available for selective areas 
of expertise. Selection of the Continue button accepts agreed 
data and Cancel returns the user to the Group Decision 
Techniques screen. The addition of a help button is intended 
to allow for the addition of help dialogue in explaining input 
format . 

9 . Techniques of Aggregation Screen 

The default value in determining techniques of aggregation 
of preferences are to utilize all four methods which include: 

• SUM- OF -RANKS 

• SUM- OF -OUTRANKING -RELATIONS 

• ADDITIVE RANKING 

• MULTIPLICATIVE RANKING 

The group can choose to individually select each method 
through the Technique of Aggregation Screen. This screen 
interface allows the user to select, via radio buttons whether 
to enable techniques of aggregation (see Figure 16) . The 
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Figure 15. Individual Criteria Selection Screen 
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Enter button accepts user input and the Cancel button returns 
the user to the Group Decision Techniques screen. 

10. The Information Exchange Screen 

This final screen interface is displayed when the user 
chooses the third radio button in the Group Norm Definition 
screen. It allows group members to set various communication 
parameters as the group norm is defined. Radio buttons allow 
either positive or negative answers to specific questions and 
two text boxes allow date and time entry with the format 
indicated (see Figure 17) . The enter button accepts imputed 
data and the Cancel button returns the user to the Group Norm 
Definition screen. 

D. CRITERIA PRIORITIZATION MODULE 

As part of the Co-oP application, each group member is 
allowed to rank the problems evaluation criteria. This module 
allows group individuals two methods in accomplishing that 
process. The group user may choose the method of Pairwise 
Comparison, otherwise known as the Analytic Hierarchy Process 
(AHP) . If the user does not require a formal decision tool, 
he may alternately choose a method of direct entry of 
priorities. A major design consideration for this module 
interface requires focusing screen presentation to the current 
input task at hand. This consideration is essential when 
utilizing pairwise comparison. This decision support tool 
allows the user to compare and evaluate two alternatives at a 
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time, and thus the user should not be distracted by other 
display elements. This module consists of five simple boxes, 
along with two interactive screen interfaces. Additional 
dialogue, error, and help screens will be covered later in a 
miscellaneous screen interface section. 

1. Prioritization of Evaluation Criteria Screen 

Similar in function to either the Group Norm 
Identification screen (see page 33) and the Problem Definition 
screen (see page 27) , this screen interface serves as the 
modules initial screen (see Figure 18) . Two separate combo 
box lists allow the user to either type in the name of the 
problem and group norm or enable a drop down list of available 
choices. Both of these require selection to initiate the 
session and identify previously defined parameters to be 
utilized. In addition the user is asked to input his name. 
It is intended upon name input, that a password dialogue box 
overlay current screen and request the five character password 
which will be verified with the group norm selected. The 
password screen will be discussed in miscellaneous screen 
designs. If the password is correct, the user chooses via 
radio buttons, the method of ranking criteria. The Continue 
button accepts user choice and displays additional interfaces. 
The Cancel button returns the user to the Co-oP Main screen. 
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2 . Pairwise Comparison Screen 

This screen interface is the input mechanism for the AHP 
process. The upper left portion of the screen represents up 
to a ten by ten positive reciprocal matrix (Ref. l:p. 131) . 
The user is queried about preference of criteria and requested 
to make a decision in the following frame box (see Figure 19) . 
The default value of "no preference" returns a unit value of 
1.0 to the corresponding two criterion in the matrix. If 
either "Yes" or "No" is selected, proper sequence is 
determined and displayed (see Figure 20) . The user is then 
asked to determine his magnitude of preference either through 
direct entry in the shown text box or manipulation of a 
sliding bar. This process continues until all criteria in 
each level are evaluated as to preference. Once completed the 
Priority Vector is determined and displayed for user reference 
and the Modify, Stats, and Graph buttons will become 
available. The Modify button opens an interface that allows 
the user to change the current data. The Stats button 
displays a simple screen displaying matrix evaluation data. 
The Graph button allows the user to view graphically via a bar 
graph (not currently available) the same information as 
displayed in the Priority Vector. The Enter button accepts 
user input. The Cancel button returns the user to the 
Prioritization of Evaluation Criteria screen. The Help "?" 
button when incorporated will identify and clarify the various 
input and display mechanisms . 
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Figure 18. Prioritization of Evaluation Criteria Screen 
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Figure 19 . Pairwise Comparison Screen 
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Figure 20. Pairwise Comparison Screen 
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3. Modification Technique Screen 

This simple dialogue box allows the user to select via 
radio buttons a method of modifying the pairwise 
comparisonmatrix. The two choices available, again made via 
radio button selection, are to modify the matrix directly or 
to select specific criteria to update (see Figure 21) . The 
Enter button accepts user input while the Cancel button 
returns the user to the Pairwise Comparison screen. 

4. Criteria Modification Screen 

This simple dialogue box is made available if the user 
opts to select criteria to update on the Modification 
Technique screen. Two combo boxes with lists of available 
criteria are provided for user selection (see Figure 22) . 
When the user selects the Enter button for data acceptance, 
these two criteria are displayed on the bottom of the Pairwise 
Comparison screen for evaluation in the same manner as 
originally input. The Cancel button returns the user to the 
Modification Technique screen without accepting any user 
input . 

5. Statistical Evaluation Screen 

This screen, used for display of information only, 
provides statistical data relating to the pairwise matrix. In 
addition it informs the user through a short message of how 
consistent the matrix inputs were (see Figure 23) . The OK 
button returns the user to the Pairwise Comparison screen. 
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Figure 21. Modification Technique Screen 
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Figure 22. Criteria Modification Screen 
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6. Priority Vector Graph Screen 

This screen is intended again only to provide informative 
data in the form of a bar graph to the user and is not 
currently available. It is intended to be the same data as 
shovm under the Priority Vector in the Pairwise Comparison 
screen only in the form of a bar graph for graphic 
interpretation for the user (see Figure 24) . Criteria are 
displayed along the bottom of the display. The OK button 
returns the user to the Pairwise Comparison screen. 

7 . Direct Input of Criteria Weights Screen 

This screen interface, displayed as a result of selecting 
the second radio button on the Prioritization of Evaluation 
Criteria screen, allows the user to input directly his 
evaluation weighing of criteria (see Figure 25) . Each level 
of criterion are intended to cycle through for his evaluation. 
Individual weights can be directly typed into the text box or 
manipulated via a sliding bar adjacent to the criteria. The 
Enter button accepts data and the next level of criteria (if 
applicable) are displayed until all criterion have been 
weighted. The Cancel button returns the user to the 
Prioritization of Evaluation Criteria screen. 
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Figure 24. Priority Vector Graph Screen 
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Figure 25. Direct Input of Criteria Weights Screen 
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E. ALTERNATIVES EVALUATION MODULE 



Building on the previous module of Criteria 
Prioritization, the Alternatives Evaluation module allows the 
user to prioritize the problem alternatives with respect to 
criterion and corresponds to the fourth process in the Co-oP 
model (see page 20) . Using methods of Pairwise Comparison, 
ELECTEE, or direct evaluation, the user evaluates the 
alternatives as identified by the group. This module 
maintains the design considerations for screen interface as 
presented in the previous module, and thus utilizes many of 
the screen interfaces already presented, with minor 
modifications. This module consists of seven dialogue boxes 
and three interactive interfaces. Additional miscellaneous 
screens with be discussed in the final section. 

1. Evaluation of Alternatives Screen 

This screen interface is of the same format and function 
as the Prioritization of Evaluation Criteria screen (see page 
47) . The only difference being the addition of four methods 
of ranking alternatives (see Figure 26) . All functions and 
controls are intended to perform in the same manner. 

2 . Pairwise Comparison Screen 

This screen, with two modifications, performs the same 
function as the Pairwise Comparison screen as presented in 
section D (see page 47) . Instead of comparing criteria, this 
interface allows the user to compare two alternatives with 
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Figure 26. Evaluation of Alternatives Screen 
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respect to a single criterion. This screen adds an additional 
text line identifying that criterion (see Figure 27) . The 
user evaluates the matrix as previously described, going 
through each criteria and looping through all three possible 
layers, if applicable, until all criteria have been used. 

3. Modification Technique Screen 

This screen is the same interface as utilized in the 
Criteria Prioritization Module. As previously presented, it 
allows the user to either update the matrix directly or select 
individual alternatives and criteria to selectively modify 
(see section D.3.). 

4. Alternative Modification Screen 

This screen interface performs the same functions as 
the Criteria Modification screen (see page 51) . The only 
additional item is the inclusion of a combo box for the user 
to select the criteria the two alternatives are being compared 
against (see Figure 28) . 

5. Statistical Evaluation Screen 

This screen performs the same function as in the Criteria 
Prioritization Module (see page 51) . Statistical data 
regarding the matrix is presented to the user if requested. 

6. Priority Vector Graph Screen 

This screen interface with one modification performs the 
same function as the Priority Vector Graph Screen in the 
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Figure 27 . Pairwise Comparison Screen 
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previous module (see page 51) . The only additional 
information is the display of criteria in which the matrix is 
being utilized for comparison (see Figure 29) . This interface 
will change in conjunction with the Pairwise Comparison 
criteria update. 

7 . Evaluation of Alternatives Using Electre Screen 

This screen interface allows the user to compare decision 
alternatives based on well defined criteria preferences. The 
user is interactively queried to evaluate an alternative based 
on weights assigned to the criteria (see Figure 30) . The user 
is looped through each alternative and is evaluated for each 
criterion. The user may enter values directly through a text 
box or manipulate the sliding box which changes the weighted 
values accordingly. The Enter button accepts current values 
and upon completion of all entries is hidden to display the 
complete Alternative Evaluation screen table. Cancel returns 
the user to the Evaluation of Alternatives screen. The Help 
button is intended to provide an overview text description of 
data entry. 

8. Alternative Evaluation Screen 

This screen interface receives inputs from the Evaluation 
of Alternatives Using Electre screen and displays them to the 
user in tabular format (see Figure 31) . This table may be 
edited by the user directly. The Enter button displays the 
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Figure 28. Alternative Modification Screen 




Figure 29. Priority Vector Graph Screen 
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Figrure 31. Alternative Evaluation Screen 
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Matrix Selection screen and the Cancel button returns the user 
to the Evaluation of Alternative screen. The Help button is 
intended to display an overview of tabular functions. 

9 . Direct Individual Evaluation Screen 

This interface allows the user to directly input 
alternative preferences based on criteria. Alternatives are 
displayed and the user either enters a weighted value directly 
via a text box next to the alternative or he manipulates the 
sliding bar corresponding to that alternative (see Figure 32) . 
Data is entered until all criteria have been evaluated. A 
corresponding normalized priority vector is displayed for the 
users reference. The Enter button accepts data and enters the 
next criterion. Upon completion the user is returned to the 
Main Screen. The Cancel button returns the user to the 
Evaluation of Alternatives screen. The Help button is 
intended to display a summary of required inputs . 
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F. DIRECT INDIVIDUAL EVALUATION MODULE 



This module may be substituted for the Criteria 
Prioritization and Alternatives Evaluation steps. If the user 
chooses to evaluate the alternatives directly without 
utilizing any of the available decision support models he has 
the option of choosing this step. The module itself only 
consists of one screen interface (see Figure 33) . Up to 15 
alternatives are presented and the user may enter his own 
weight factor, either directly in a text box or manipulating 
the associated sliding box. Normalized priority vectors are 
displayed for the users information. The Enter button accepts 
user input and the Cancel button returns the user to the Main 
screen. The Help button is provided to present a text outline 
of the current process. 

G. COMPUTATION OF GROUP DECISION MODULE 

This module consists of three screen displays, one simple 
input dialogue box and three output screens. The purpose of 
these screen interfaces is to display to the users the group 
problem results in various formats. Help formats will be 
discussed in general in the miscellaneous screen section. 

1. Computation of Group Results Screen 
This screen interface allows the user to select both the 
group problem and group norm from combo boxes (see Figure 34) . 
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Figure 33. Direct Individual Evaluation Screen 
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This input is used in determining group results. 
Additionally, the current user is asked to enter his name 
which will then prompt a password screen in order to verify 
the user is part of the group norm. If he is, he may then 
select various output formats using the appropriate radio 
button selection. The Enter button accepts user button 
selection and displays the corresponding screen. The Cancel 
button returns the user to the Main Co-oP screen. 

2 . Cardinal Rankings Screen 

This screen serves to display individual group members 
decision results to the group. This broadcasting of 
individual results is subject to restrictions as set forth in 
the group norm module. The current user selects via a combo 
box the member whose results he desires to see (see Figure 
35) . The alternatives along with corresponding weight factors 
are displayed as a list. The OK button returns the user to 
the Computation of Group Decision screen. The Cancel button 
returns the user to the Main Co-oP screen. 

3 . Ordinal Rankings Screen 

This screen interface functions similarly to the Cardinal 
Ranking screen. Users select individual group members to view 
the results of their rankings (see Figure 36) . They may view 
several different group members alternative rankings by 
selecting different names from the combo box. Alternatives 
are ranked ordinally in list format. The OK button returns 
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Figure 34. Computation of Group Decision Screen 




Figure 35. Cardinal Rankings Screen 
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the user to the Computation of Group Decision screen. The 
help button is intended to amplify information presented. 

4. Group Results Screen 

This screen interface allows the user to view the groups 
final results (see Figure 37) . The alternatives are 

cardinally with four adjacent methods of ranking as follows: 

• R1 : Maximum Additive Ranking 

• R2 : Maximum Multiplicative Ranking 

• R3 : Maximum Sum of Outranking Relations 

• R4 ; Minimum Sum ot the Ranks 

These methods would be readily available in the help text. 
The OK button returns the user to the Computation of Group 
Decision screen. 

H. IDENTIFY NEGOTIABLE ALTERNATIVES MODULE 

Although currently not available as an interface this 
modules intention is to help the group MCDM analyze and 
possibly resolve negotiation differences [Ref. l:p. 62] . The 
Negotiable Alternative Identifier (NAI) is a proposed 

algorithm support decision makers analyze differences when 
techniques of aggregation of differences fail to find a 
unanimous decision. It is based on a three step 

expansion/contraction/intersection mechanism that attempts to 
optimize a solution. 
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Figure 36. Ordinal Rankings Screen 
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I. MISCELLANEOUS SCREEN INTERFACES 



There are several additional screen layouts that may be 
utilized by this interface. The Help screen allows for either 
short informative text message or an extended list describing 
a screen function or model requirements (see Figure 38) . 
Exiting the Help screen via an OK button returns you to the 
previously displayed screen. Help messages should be short 
and precise. If descriptive outlines are used, present them 
in a numbered step process. Error messages alert the user to 
possible problems with data input or application deficiency. 
As in the case of Help messages, they should be short and to 
the point with the OK button returning the user to the 
previously displayed screen (see Figure 39) . 
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Only files with a "*.def extention will be listed in 
the File box. You may select a file by double 
clicking it or clicking on the OK button after 
selecting the file. 




Figure 38. Help Screen 




Figure 39. Error Screen 
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IV. SUMMARY AND RECOMMENDED FUTURE RESEARCH 



A. SUMMARY 

The intent of this research was to develop a graphical 
interface for Co-oP, a tool in support of group decisions. 
The proposed Graphical User Interface had to adapt to an 
already established educational tool and maintain the Co-oP 
applications framework and communication parameters in 
presenting GDSS models. Utilizing common GUI components and 
building on general principles of interface design, this GUI 
attempts to present a complex set of decision support tools 
that encourage user interest and participation through 
experimentation. With the user in mind, this prototype has 
mechanisms that allow him to control the sequence of events, 
screen designs that are consistent both in presentation and 
control devices, and focused screen designs which provide a 
clear conceptual picture of decision models presented. A 
major goal in this user interface design was to allow the user 
to be in command of the application and not let the 
application control user interaction. 

B. RECOMMENDED FUTURE RESEARCH 

At present this interface is a graphical screen shell, 
providing the visual interface to the Co-oP model. Areas that 
require continued research and implementation include: 
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• adding code to support screen implementation and provide 
data retrieval and error checking 

• adding the AHP and ELECTRE algorithms 

• conducting extensive user surveys through application test 
use and evaluation 

This research design has provided the basis for an ideal 
Graphical User Interface. The design framework is in place 
but requires additional research and development in order to 
extend and explore the benefits the Co-oP Multiple Criteria 
Group Decision Making model and expand on new topics it may 
uncover . 
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